QRZ! Ham Radio 4/QRZ Ham Radio Callsign Database - Volume 4.iso/digests/tcp/940110.txt

Internet Message Format | 1994-11-13 | 10KB

Date: Sun,  5 Jun 94 04:30:02 PDT
From: Advanced Amateur Radio Networking Group <[e-mail]>
Errors-To: [e-mail]
Reply-To: [e-mail]
Precedence: Bulk
Subject: TCP-Group Digest V94 #110
To: tcp-group-digest


TCP-Group Digest            Sun,  5 Jun 94       Volume 94 : Issue  110

Today's Topics:
                     Announce: JNOS/Linux ALPHA.4
                         problem with wampes

Send Replies or notes for publication to: <[e-mail]>.
Subscription requests to <[e-mail]>.
Problems you can't solve otherwise to [e-mail].

Archives of past issues of the TCP-Group Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives".

We trust that readers are intelligent enough to realize that all text
herein consists of personal comments and does not represent the official
policies or positions of any party.  Your mileage may vary.  So there.
----------------------------------------------------------------------

Date: Sat, 04 Jun 1994 20:04:45 -0400
From: "Brandon S. Allbery" <[e-mail]>
Subject: Announce: JNOS/Linux ALPHA.4
To: [e-mail]

By the time you receive this, the ALPHA.4 release of JNOS/Linux should be in
the incoming directory at ucsd.edu.  The complete path name is

    ucsd.edu:/hamradio/packet/tcpip/incoming/j109lxA4.tgz

This, like ALPHA.3, is a full source release; however, the DOS-specific files
have been omitted from this release.

A summary of the changes since ALPHA.3 follows my .signature.

++Brandon
--
Brandon S. Allbery       [e-mail]         [e-mail]
The FUDs at Microsoft are shouting "Kill The Wabi!"

Bugfixes and changes since ALPHA.3:

* "ls"/"dir" of nonexistent file/directory no longer kills NOS

  I was using a findlast() function to close the directory opened by the
  findfirst()/findnext() clone, but they already close the directory on
  EOF or failure.  There may now be file descriptor leaks if findfirst()/
  findnext() is not run in a loop until -1 is returned, but the code to cope
  with this already exists:  a flag is now set to make sure the directory
  isn't closed twice.

* Telnet now works right with *ix clients

  I adapted the 1.10 patches for 1.09.  The same caveats apply as with 1.10.

* Partial support for FTP "SYST" command

  All that is currently done by the client is to print the system type as a
  reminder to the user.  I will implement *ix-like automatic file type setting
  later.

  The server responds to "SYST" with a 215-level response similar to that in
  1.10c.

* New asy driver

  The loss of large packets is now cured:  EAGAIN/EWOULDBLOCK wasn't being
  trapped on writes.  Also, the driver parameters can now be configured at
  runtime so that one can balance between the ALPHA.1 behavior, which tended
  to "hog" the process servicing busy asy ports, and the ALPHA.2 behavior
  which preferred the other tasks but could drop incoming packets on a very
  heavily loaded frequency.

  The "asy" command now honors the buffer length.  Previously, a fixed-size
  64-byte buffer was used (traditional *ix clist size).  It can be changed
  dynamically with the "asyconfig" command.  Smaller buffers improve the
  response of other NOS tasks but eat more CPU time; larger buffers will
  better keep up with busy channels but will "starve" other NOS tasks (you
  can use "rxqueue" below to avoid this, however).  A good setting is a
  little larger than your "paclen" (or the MTU on a SLIP/PPP link).

  The input and output tasks now support a simple form of inter-task flow
  control, using the "rxqueue" and "txqueue" parameters:  after "rxqueue"
  packets are put in the network "hopper" by the asy receive task, it blocks;
  after "txqueue" packets are transmitted by the asy transmit task or if
  EAGAIN/EWOULDBLOCK is returned on a write, it blocks.  The default is the
  ALPHA.3 behavior, which is an rxqueue/txqueue of 1.  For the "hoggy" style
  used by ALPHA.1, set rxqueue and txqueue very large.  I have both set to
  5 on my asy links and to 2 on my SLIP-to-Linux link, and it seems to be a
  fairly good compromise.

  The "asystat" command now shows some useful statistics that may be of help
  in tuning these:

net> asystat
144.99: 9600 bps, packet size 255, RTS/CTS disabled, carrier disabled
  RX: ints 2 chars 73 puts 2 buf 1024 rxqueue 5 qlen 0 ovq 0 block 0
  TX: ints 1 gets 0 chars 57 txqueue 2 qlen 0 ovq 0 block 0
linux: 38400 bps, non-blocking, RTS/CTS disabled, carrier disabled
  RX: ints 0 chars 0 puts 0 buf 1024 rxqueue 2 qlen 0 ovq 0 block 0
  TX: ints 0 gets 0 chars 0 txqueue 2 qlen 0 ovq 0 block 0

  "ints" is the number of times pwait() returned control to the task,
  indicating that select() detected pending data on input or a packet became
  available for output.  "chars" is the number of characters read/written.
  "buf" is the current receive buffer size, as specified in the attach
  statement or the "asyconfig" command.  "rxqueue"/"txqueue" is as described
  above.  qlen is the instantaneous queue size (number of packets).  ovq is
  the number of times queue flow control (described above) was triggered.
  "block" is the number of times read/write tried to block (in the case of
  reads, the number of times it tried to block after data was claimed to be
  available).

  The "asyconfig" command can be used to examine or set the new asy
  configuration parameters:

    asyconfig <iface> <parameter> [<value>]

  <iface> is any asy interface.  <parameter> is one of:

    bufsize        receive buffer size
    rxqueue        receive flow-control threshold
    txqueue        transmit flow-control threshold

  Any of these can be changed at any time.

  RTS/CTS flow control is now supported, but untested; I don't have anything
  conveniently available which supports it to test it.  As with the DOS
  version, it is controlled with

    param <iface> RTS <0|1>

  The default is 1, for compatibility with previous Linux releases.  The DOS
  DTR parameter will *not* be supported, because the Linux serial driver has
  effectively complete control over DTR.

  In addition, a new input mechanism has been provided, using the "f trigger"
  parameter used by the DOS version for 16550A FIFO control (that function
  is handled by the Linux kernel; get the "setserial" package if you need to
  tune the FIFO trigger level).  The value can range from 0 to 255; if it is
  0, the original input mechanism is used, otherwise blocking reads are used
  with termios VMIN set to the specified value.  At the moment there is no
  error checking; if you set the buffer size smaller than VMIN you could lose
  incoming data.  Under some *ixes setting it to anything other than a
  multiple of VMIN could cause problems.  (I know that under Ultrix, you would
  need to set bufsize equal to VMIN --- but I don't think JNOS has been ported
  to Ultrix yet :-)  The tradeoff here is that, on a mostly quiet channel,
  input could be delayed by up to 1/5 second, but on an active channel JNOS
  will use *much* less CPU time and generally will be much more efficient.

  Summary of the current "attach" command:

attach asy ttySX - <slip|ax25|ppp> <iface> <bufsize> <mtu> <speed> [<flags>]

  The argument after the device ttySX should be zero or a hyphen (-).  It may
  be used in future versions.

  The device should be a ttySX, not a cuaX.  cuaX can cause problems for
  reasons I don't fully understand at present.

  <bufsize> is the read buffer size described above.

  The only <flag>s supported are "v" for Van Jacobsen SLIP compression and
  "f triglevel" to use the VMIN read mechanism.

* The Command flow-control throttle from incoming mail has been fixed

  All previous fixes tried to avoid the use of an asynchronous I/O mechanism,
  since it complicates the "curses" session manager.  Unfortunately, there
  *is* no proper fix that doesn't involve asynchronous I/O, since the messages
  are inherently asynchronous.  There is now an asynchronous output entry
  point in the session manager, which is used for these messages.

* The FTP client "lcd" command no longer fails

  dir_ok() wasn't setting up variables properly.  Sometimes this resulted in
  a "harmless" failure; other times NOS dropped core.

* JNOS will read the config file ".nosrc" if no -f option is specified

  This is primarily to support default session managers (see below), but
  may also be used for color information in the future.  You may also want
  to copy compat.cfg to .nosrc if you still don't want to rearrange your files
  from ALPHA.2.

* You can specify the default Command and Trace session managers in the config
  file (either .nosrc or the one read with the -f option).

    Command = sessmgr[:options]
    Trace = sessmgr[:options]

Additionally, a number of "dead ends" were pursued but are no longer in the
source.  These include color support (the color commands were asynchronous to
the output, resulting in scrambled colors) and a trace server (a positive
feedback loop results if someone tries to trace the interface they're on, and
there's no way to prevent it).  The abortive color support did lead the way to
the answer to the Command flow-control problem, however (if you've been paying
attention, you'll note that it's the same problem in reverse).  Another
reason color was dropped is that ncurses presently ignores background colors.

------------------------------

Date: Sat, 4 Jun 1994 13:10:50 +0100 (MET DST)
From: [e-mail] (Hans Alblas)
Subject: problem with wampes
To: [e-mail]

I have a problem with the wampes software

When wampes recieves fragmented upd frames with ip-ip encapse
headers then wampes will hangup for some time.
While recieving the first udp frame fragment goes wampes in a waitstate
(the first recieved fragmanted udp frame piece is not shown in
 the trace at this moment)
after some time (when all fragmentation pieces are together) will
the system run's again normal but on our slowly radio net will it
take some time befor wampes is out of his hangup situation.
How can i resolve this problem?
In this situation is it impossible to get een zone domain transfer
from a domain server via a wampes gate even via fast Internet!

Groetjes de Hans


--
Hans Alblas           Email:  [e-mail]
Egstraat 34           Packet: [e-mail]
6418JA Heerlen        IP: [44.137.4.10] (AmPR-Net)

------------------------------

End of TCP-Group Digest V94 #110
******************************